1. Field of the Invention
The present application relates generally to an improved data processing apparatus and method and more specifically to an apparatus and method for providing and using optimized function variants in compiled code when return codes of function or method calls are ignored upon return.
2. Background of the Invention
A compiler is a computer program, or set of programs, that translates source code, in a high-level programming language, into code of a lower level language, e.g., assembly language or machine language. Commonly, the output of the compiler has a form suitable for processing by another program, such as a linker, but it may also be output in a human-readable format. The most common use of a compiler is to translate source code such that an executable program is generated. Compilers are likely to perform many, or all, of the following operations: lexical analysis, pre-processing, parsing, semantic analysis, code generation, and code optimization.
One type of code optimization that may be performed by a compiler is to perform inline expansion, i.e. inlining, of function calls or method calls to achieve a performance improvement over non-inline function, or method, calls. That is, functions within source code may be specified as inline function calls thereby requesting that the compiler inline the function, i.e. copy the complete contents of the function, into the resulting translated code. Inline expansion is typically used to eliminate the inherent time overhead that occurs in calling a function. Inline expansion is typically used for functions that execute frequently, as this overhead is more significant in this case. Inlining also has a space benefit for very small functions and is an enabling transformation for other optimizations.
While inlining may provide a performance benefit, there are some inefficiencies associated with inlining. One major inefficiency is the problem with code bloat. That is, each time an inlined function or method call appears in the source code, it is replaced with the full content of the function or method being called. This may significantly increase the size of the resulting executable code, e.g., if a function is called 200 times, there will be 200 copies of that function. This code bloat may lead to slower performance and “thrashing.” For example, if the executable size of the program is too big, the system may spend most of its time going out to disk to fetch the next chunk of code thereby causing the system to “thrash” on memory pages.
In addition, often times in code functions are called without checking the return code or value. For example, a memory allocation function may be called in order to allocated a register but the calling code may not do anything with the value returned by the memory allocation function. When this happens, all the code that went into generating the return value may result in wasted processor cycles and memory. This is made even more of an issue if this function code is inlined and thus, copied many times into the resulting executable code.